fix(soroban): reject unsupported ABI types before codegen#1903
Open
mohamedbasuony wants to merge 1 commit into
Open
fix(soroban): reject unsupported ABI types before codegen#1903mohamedbasuony wants to merge 1 commit into
mohamedbasuony wants to merge 1 commit into
Conversation
5d3f8fc to
85c288a
Compare
Contributor
|
This change shouldn't be in Changes should be mostly in |
salaheldinsoliman
requested changes
May 13, 2026
Contributor
salaheldinsoliman
left a comment
There was a problem hiding this comment.
Left a comment
Contributor
Author
|
Thanks, I see your point. I put the checks in sema as target validation, but I agree that this is too early/general for Soroban-specific ABI handling. The PR will be updated so that it handles unsupported Soroban ABI cases in the emit/codegen path, closer to the encoding/decoding logic. |
Move unsupported Soroban ABI validation into the Soroban codegen path before dispatch wrapper generation, encoder/decoder lowering, spec emission, and LLVM emission can hit unsupported constructs. Add diagnostics for unsupported Soroban external/public ABI surfaces, including unsupported bytes parameters, bytes/string/struct/array returns, public accessor returns, multiple external returns, unsupported event argument types, and internal string-helper patterns that could otherwise reach LLVM/Inkwell failures. Target-gate the Soroban validation and early returns so non-Soroban diagnostic accumulation remains unchanged. This avoids user-triggerable panic!, todo!, unimplemented!, and LLVM assertion paths from hyperledger-solang#1897 while keeping supported event emission, public string accessors, internal bytes helpers, and non-Soroban targets unaffected. Signed-off-by: mohamedbasuony <mohamedbasuony@aucegypt.edu>
85c288a to
870f599
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the compiler-side Soroban diagnostics covered by #1897.
Unsupported Soroban paths could previously reach codegen, Soroban encoder/decoder logic, spec emission, or LLVM and fail with internal panics,
todo!(),unimplemented!(), Inkwell errors, or LLVM assertions. This PR adds Soroban codegen-side validation so those user-triggerable cases are reported as normal Solang diagnostics before the unsafe paths are reached.What changed
semaand into the Soroban codegen path.Notes
Verification
Ran locally:
cargo fmt --all -- --checkcargo build --workspacecargo test --test sorobancargo test --test contract solana_contracts -- --nocapturecargo clippy --workspacecargo test --workspaceManual checks:
dynamic_bytes_arg.sol: emits a normal diagnostic; old Soroban decoder panic is gone.string_return.sol: emits a normal diagnostic; old LLVM abort is gone.event_panic.sol: still compiles on this checkout.examples/soroban/token.sol: still compiles with existing warnings.Fixes #1897.